home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 1 / NetNews Offline Volume 1.iso / news / fido / ger / amiga / 4252 < prev    next >
Internet Message Format  |  1996-03-16  |  8KB
  1. From: Axel_Doerfler@p23.f413.n2449.z2.fido.sub.org (Axel Doerfler)
  2. Organization: Point #23 der AmigaXess
  3. Path: f413.n2449.z2.fidonet.org!not-for-mail
  4. Newsgroups: fido.ger.amiga
  5. Subject: Re: Brechreiz!
  6. Message-ID: <MSGID_2=3A2449=2F413.23=40fidonet_23B37621@fidonet.org>
  7. References: <199511221753.a19876@bl.maus.de>
  8. Date: Sat, 25 Nov 1995 18:38:30 +0200
  9.  
  10. Hi Michael,
  11.  
  12. Am 22 Nov 95 hast du zu ½Re: Brechreiz!╗ an Norbert Bendl geschrieben:
  13.  
  14.  MF> [MUI]
  15.  AD>>> Langsam nicht, aber auch nicht gerade schnell...
  16.  MF> NB>
  17.  NB>> Aber viel mehr wird sich da nicht mehr rauskitzeln lassen.
  18.  
  19.  AD>>> Man kann die Hardwareanforderungen eigentlich schon sehr klein
  20.  AD>>> halten, wenn man ein ganz klein wenig programmieren kann... auch MUI
  21.  AD>>> muesste diesem "allgemeinen Trend" nicht folgen (womit ich dem Stefan
  22.  AD>>> Stunz jetzt aber nicht seine Leistungen absprechen will).
  23.  
  24.  NB>> Schildere doch mal genauer, wie Du Dir das vorstellst.
  25.  
  26.  MF> oje oje, ich wuerde auch gerne mal wissen, ob der schreiber der Vormail
  27.  MF> ueberhautp im Stand waere, etwas aehnliches wie MUI zu programmieren.
  28.  
  29. Nun, da ich der Schreiber dieser Mail bin, kann ich dir sagen, dass ich mich
  30. zumindest im Stande sehe, so etwas aehnliches wie MUI zu programmieren (die
  31. 3.0er habe ich allerdings noch nicht gesehen). Ob es dann so schnell wie MUI
  32. waere, kann ich dir auch nicht sagen; dass kaeme auf einen Versuch an.
  33.  
  34. Weiterhin kann ich dir allerdings sagen, dass das nicht der Punkt ist. Ob *mir*
  35. MUI zu langsam ist oder nicht, haengt einfach nicht davon ab, ob *ich* auch so
  36. etwas programmieren koennte, sondern vielmehr davon, dass dies mein
  37. persoenlicher Eindruck ist.
  38. Diesen kann ich in diesem Fall noch durch das Vorhandensein von
  39. Alternativen, wie der gtlayout.library, untermauern.
  40.  
  41. Zum Vergleich: Wenn ich als Amiga-Anwender sage, der PC sei mir unter Win95 zu
  42. langsam, wird dieser Eindruck nicht dadurch vermindert, dass ich persoenlich
  43. nicht in der Lage bin, einen PC zu bauen, oder auch so ein Monster wie Windows
  44. zu programmieren.
  45.  
  46. Waere der PC das einzige System, gaebe es also keine Alternative, waere dies
  47. wohl mein Problem, im Falle von MUI gibt es allerdings Alternativen, die ich
  48. bevorzuge. 
  49. Das ist der Punkt.
  50.  
  51.  MF> Allgemein gesagt kommt es mir vor, wie wenn echt viel zu viel an
  52.  MF> solchen Sachen wie MUI, oder auch an bestimmten Teilen des OS
  53.  MF> rumgemeckert wird. Ich bin viel mehr der Meinung, dass ein Grossteil der
  54.  MF> meckerer nicht mal annaehernd dazu in der Lage waere, auch nur einen
  55.  MF> Bruchteil der Software die kritisiert wird, auch nur halb so schnell zu
  56.  MF> programmieren wie die Originalautoren. Das MUI ist vielleicht etwas
  57.  
  58. s.o.
  59.  
  60.  MF> zaeh, und Assemblerhacker wuerden es, wenn es sein muss garantiert um
  61.  MF> 50 - 100% schneller machen aber sicher wuerde bei denen jedes weiter
  62.  MF> Feature immer mehr in die Unmoeglichkeit geraten. Zu solcher Software
  63.  
  64. Tolles Vorurteil gegenueber Assemblerfreaks :)
  65. Man kann auch in C schlecht *und* gut schreiben.
  66.  
  67.  MF> gehoert nunmal viel mehr, als nur die aktuelle Funktionalitaet und
  68.  MF> Geschwindigkeit, solche Software muss gut geplant und sollte aufs
  69.  MF> unendliche erweiter- und verbesserbar entwickelt werden und damit
  70.  MF> alleine blaeht sich ein System auf und wird langsamer, man sollte
  71.  
  72. Diese Ansicht ist so nicht korrekt - die Moeglichkeit einer Erweiterung blaehen
  73. das System nicht zwangsweise auf.
  74. Man plant eigentlich voraus, um solche Auswirkungen zu vermeiden... ;-)
  75.  
  76.  MF> einfach an alle moeglichen zukuenfitgen Erweiterungen denken und wer
  77.  MF> heute noch mit dem optimieren auf diverse Grafikkarten oder gar
  78.  MF> eingebaute ChipSets oder vorhandene Funktionen an so ein System
  79.  MF> rangeht, der kann spaetestens Uebermorgen mit einer Neuprogrammierung
  80.  MF> anfangen.
  81.  
  82. Nun, auf das OS im Ganzen bezogen, hast du sicherlich recht, doch benoetigt man
  83. bei GraKas trotzdem eigene Treiber, die dann ruhig auch optimiert sein duerfen.
  84.  
  85.  MF> Ich denke auch, dass viele OS-Kritiken einer Zukunftsplanung nicht
  86.  MF> standhalten haetten koennen und dass sich die ehemalige DevCrew viel
  87.  MF> mehr Gedanken ueber ihre Funktionen und Entwicklungen gemacht hat, als
  88.  MF> es sich die meisten hier ueberhaupt vorstellen wollen. Man sollte nicht
  89.  MF> dauernd an den etwas langsameren Datatypes oder an der Art, wie die
  90.  
  91. Aha.
  92. Dir geht es also im tiefsten Herzen um die OS-Kritiker ?! :-))
  93. Wenn es um das OS geht, muss ich dir voll und ganz zustimmen.
  94.  
  95.  MF> WBPattern gewechselt werden meckern, sondern sich einfach mal daran
  96.  MF> erfreuen, wie wirklich inovativ das OS wirklich ist, alleine das
  97.  MF> Library Konzept, die Einfuehrung der Datatypes, die Localisierung ueber
  98.  MF> die Catalogs (gibts fuer ein Prog, das Locale unterstuetzt keine
  99.  MF> Spanischen Oberflaechen Katalog, dann erstellt ihn halt kurz jemand, der
  100.  MF> die Originalsprache uebersetzen kann) Systemtools ueber ein so
  101.  MF> einheitliches Interface wie die Commoditie Schnittstelle
  102.  MF> einzubinden... das alles sind wirklich extrem gute Ansaetze die man zu
  103.  MF> damaligen Zeiten auf anderen Systemen meines Wissens nach vergeblich zu
  104.  MF> suchen hatte und auch in einigen Bereichen noch heute zu suchen hat.
  105.  
  106. Das ist genau auch meine Meinung :-)))
  107.  
  108. Um doch mal wieder auf den Anfang zurueckzukommen:
  109. Es gibt fuer mich keine Alternative zum AmigaOS - davon abgesehen brauche ich
  110. auch gar keine, denn bis auf die noch zu integrierende GraKa-Unterstuetzung bin
  111. ich voll zufrieden damit.
  112.  
  113.  AD>>> Man koennte aus jedem PC mit einem richtigen OS mehr herausholen, als
  114.  AD>>> das bisher getan wird, auf dem Amiga sollte es doch vermeidbar sein,
  115.  AD>>> es soweit kommen zu lassen.
  116.  NB>> Ich sehe keine  Gefahr,  dass  wir  durch  MUI  solche  Zustaende
  117.  NB>> bekommen. Wenn die Programmierer sich auf MUI einlassen, dann tun sie
  118.  NB>> das ja freiwillig. Also sehen  sie  mit  Sicherheit  Vorteile darin.  
  119.  NB>> Dasselbe  gilt  fuer  die  Anwender,  die  MUI-Programme benutzen. Es
  120.  NB>> ist ja nicht  so,  dass  da  irgendein  Mega-Konzern waere, der uns
  121.  NB>> MUI aufs Auge drueckt, MUI und nichts anderes.
  122.  
  123.  MF> Man muss auch mal sagen, dass man mit einem 68K mit 7.14 MHz einfach
  124.  MF> nicht mehr aktuell ist, ist halt das gleiche, als wenn man sich noch
  125.  MF> mit nem TV als Monitorersatz rumplagen muss. Sowas hindert leider auch
  126.  MF> extrem den Fortschritt. Ich muss es auch am eigenen Leib spueren ...
  127.  
  128. Moment. Gegenteiliges habe ich nicht behauptet, nur bin ich der Meinung, dass
  129. man die vorhandenen Leistungen auch ruhig ausnutzen darf (daher AmigaOS und kein
  130. Windows :).
  131.  
  132.  MF> ich bin nach wie vor daran, ein Systemkonformes Adventure zu schreiben
  133.  MF> und hab wirklich fantastische Grafiken dafuer ... auf dem Papier (die
  134.  MF> Vollbild Hintergrund Bilder) diese werden dann mal gescannt ... toll,
  135.  MF> in 24 BIT und 800*600 sehen sie echt noch wahnsinnig aus ... dann aber
  136.  MF> kommt das boese erwachen ... 320*240 in 256 Farben ... sieht absolut
  137.  MF> beschissen aus (ok sind noch nicht nachbearbeitet, aber das rettet auch
  138.  MF> nicht mehr viel) und ist ja fuer viele, die noch ein OCS/ECS haben viel
  139.  MF> zu aktuell, das ganze auf 640*480 getestet und die GFX sind
  140.  MF> beinahe nicht mehr wiederzuerkennen ... sowas waere fantastisch ... Prog
  141.  MF> kurz geaendert und auf der GraKa getestet ... prima ... dann auf nen
  142.  MF> AGA Rechner ... puh, vieeeell zu langsam ... also was machen, entweder
  143.  MF> wieder auf 320*240 = beschissen aber relativ viele koennen es nutzen
  144.  MF> oder wirklich 640*480 aber dann nur fuer GraKa (und man muss sich noch
  145.  MF> laesterei bezueglich Speed anhoeren).
  146.  
  147. Hmmm. Der Fall liegt IMHO etwas anderes, da du die Grafiken ja einschraenken
  148. willst, um die Geschwindigkeit zu verbessern - MUI soll aber nicht
  149. eingeschraenkt werden, sondern nur die Hardware besser nutzen.
  150. In deinem Fall wuerde ich fuer die 640x480-Loesung plaedieren, weil
  151. digitalisierte Grafiken nicht fuer niedrige Aufloesungen geeignet sind.
  152. Nebenbei: es gibt auch noch Mittelwege zwischen den Extremen (320x240 und
  153. 640x480) z.B. ist es haeufig moeglich, weniger Farben anstelle von niedriger
  154. Aufloesung zu nehmen - sieht meiner Meinung nach meistens besser aus...
  155.  
  156. Adios...
  157.          Axel.
  158.